When providing programs to requesting client locations (for example, viewer's television sets), an MPEG transport stream is created. An MPEG-2 transport stream, comprising packets of 188 bytes, combines one or more programs, with common or independent timebases, into a single stream. The input program streams, which may be combined into the transport stream, can have a constant bit rate (CBR) or a variable bit rate (VBR), wherein a CBR stream has a known bit rate associated with the stream, while a VBR stream has no specified bit rate. MPEG-2 transport streams can be delivered via cable, satellite or air from a program provider location to a viewer location.
A transport stream carrying more than one program is referred to as a Multi-Program Transport Stream (MPTS). A transport stream multiplexer is a device that combines multiple programs to form a single transport stream. In doing so, the multiplexer must guarantee the integrity and accuracy of the individual timebases of the programs, since the correct timebase is necessary for the decoding of each individual program at the receiving location. The process of extracting the individual program streams from the transport stream is done by a demultiplexer.
FIG. 1 provides a block diagram of an environment wherein the multiplexing and demultiplexing occurs. A requesting client, viewer location 100, “requests” a program, either by simply tuning to a designated program display channel on a set top box or by entering a so-called “pay per view” request which will be sent via its communications component 102 to server 1 at 110. Server 1 may be a cable provider's headend, or other comparable program servicing facility. If server 1 has a copy of the program in its storage location 118, the program will be accessed, multiplexed into a stream at multiplexer 116, and provided via communications component 112 to the client. Should more than one program be requested, and both be available at server 1, the created stream will be an MPTS that is provided to client location 100 for demultiplexing at demultiplexer 104 and then provided for viewing at display 103 (e.g., a computer or television set). If server 1 does not have a copy of a requested program in its storage 118, it will communicate with another server, shown as server 2 at 120, to obtain a copy. Upon receipt of a request at the communications component 122 of server 2, a copy of the requested program is retrieved from storage 128, multiplexed in multiplexer 126 into an MPEG-2 stream, and then provided to communications component 122 for transmission to server 1. Server 1 must then demultiplex the stream received from server 2 at its demultiplexer 114, followed by remultiplexing the stream, for example with a program accessed from local storage 118, to provide an MPTS for transmission from communications component 112 to the client 100.
A remultiplexer is a component, illustrated at 115 in FIG. 1, which performs both the demultiplexing and multiplexing functions. FIG. 2 illustrates in greater detail a prior art remultiplexer 215 having both demultiplexing and multiplexing capabilities. Upon receipt of an input transport stream, at buffer 202, requested program or programs are extracted from the input stream, demultiplexed at demultiplexer (DEMUX) 204 and then provided to individual program buffers, 206, 216 and 226. A decision is made at the program buffers if the buffered program should be added to the output stream, copied into storage, or dropped. The decision is generally based on the contractual arrangement previously entered into by the viewer and the program provider. For those programs which are to be passed to the output stream, the demultiplexed programs, as well as any programs which are being inserted from local storage, are provided to the multiplexer (MUX) 208 which multiplexes the programs into the output transport stream and provides them to output buffer 210 for streaming in accordance with known techniques. A bypass switch 201 is provided to allow streams to pass through the provider location in the event of scheduled maintenance on or a failure of the remultiplexer.
Conducting both demultiplexing and multiplexing at the remultiplexer is costly in terms of time and program integrity. Both demultiplexing and multiplexing can introduce sources of error into the streams unless care is taken to ensure that timebase information is correctly applied. Program streams carry timebase information in packets having Program Clock Reference (PCR) timestamps, which are included at least every 100 mS. However, if the original program is changed, for example at buffer 202 or at program buffer 206, 216 or 226, by adding or removing packets before the multiplexing process, as further discussed below, the timebase information on the original program may become inaccurate and may compromise the decoding/demultiplexing process. The timebase information on the entire program would need to be adjusted before multiplexing it, which introduces both cost and delay in the remultiplexer.
Adding packets may be necessary if one wants to encrypt some elements of a program, to add watermarks, to insert tracking information before transmission, or to insert functions such as closed captioning, electronic program guides, or data for interactive services. Removal of packets may be done to remove partial information of a program (like an audio channel). Other packets which would frequently be added to a transport stream include packets not referenced in the PSI tables (unreferenced packets) such as packets containing DVB and ATSC information.
Every packet in a transport stream contains an ID (hereinafter referred to as “PTD”). A program is defined by a set of PIDs. A special PID (0x1fff) identifies the idle packet PID that is used as padding in a transport stream. However, in an MPTS transport stream there is no guaranteed way to determine if an idle packet belongs to a program or is a padding packet (which is the result of a multiplexing process). A transport stream includes tables (PSI tables), which identify the number of programs carried by the transport stream and which list the PIDs of each program. The transport stream may additionally include the aforementioned unreferenced packets, such as DVB and ATSC specific packets which are not referenced in the tables. During the demultiplexing process, the unreferenced packets are typically sent to a separate buffer, 226 of FIG. 2, and then reinserted into the output transport stream by the multiplexer MUX 208. However, the original bit rate of the unreferenced packets cannot be determined. This ambiguity, along with the idle packet problem, creates a potential, if not a likelihood, that timing information of the original stream will be compromised. Prior art systems, therefore, can transform an original CBR program before the multiplexing process into a VBR program after the demultiplexing. If the extracted program is to be further multiplexed (e.g., a program provided from server 2 which will be further multiplexed at server 1 for transmission to the client), it will potentially require a conversion from VBR to CBR stream. The demultiplexed program can, however, only be reconstructed to its original CBR form if the original bit rate is known. However, an MPTS does not carry information about the bit rates of the programs that it contains. That original bit rate information has to be supplied to a demultiplexer by another means (e.g., a software application).
One difficulty encountered in the remultiplexing of VBR streams is that there may not be sufficient instantaneous bandwidth to transmit all of the requested streams. The bandwidth profile of each stream can be adjusted to guarantee that they all fit in the output channel. However, this adjustment requires real-time processing of the streams before multiplexing, which is a very processing intensive task and can add significant delays.
What is needed, and what is an object of the present invention, is a system and method to allow remultiplexing of CBR and VBR streams without pre-processing or demultiplexing programs.
Another object of the present invention is to provide a system and method that allows multiplexing of programs that have been partially changed, without the need for adjusting the timebase information.
Yet another object of the present invention is to insert a remultiplexer into an already active MPEG-2 transport stream path with minimal disruption.